home *** CD-ROM | disk | FTP | other *** search
/ PD Collection CD 1 / PD Collection CD 1.iso / programer2 / sdls / Errata < prev   
Text File  |  1995-06-21  |  5KB  |  119 lines
  1. SDLS RELEASE 1.03 ERRATA
  2.  
  3. _____________________________________________________________________________
  4.  
  5.  
  6. The section describing the macros for writing DLLs in C is incorrect. The way
  7. the macros work is described below.
  8.  
  9.         The preprocessing for the dll.h and the replacement standard header
  10.         files are controlled by two macros:
  11.  
  12.         _DLL            Define (e.g. using -D_DLL at the command line) to
  13.                         indicate that we are compiling code to be placed in
  14.                         a Dynamic Link Library.  Do not define this macro
  15.                         if compiling for a statically linked version of the
  16.                         library.
  17.  
  18.                         Precisely, defining _DLL will cause accesses to
  19.                         global SharedCLibrary variables (e.g. stdin or
  20.                         errno) to be translated into calls to find the
  21.                         address of the client's copy of these variables.
  22.                         Also, it enables translation of _dllEntry(name)
  23.                         into _dllEntry_name.
  24.  
  25.         _dll_NODLL      Define (e.g. using -D_dll_NODLL) to indiciate that
  26.                         we should not perform any name translations or use
  27.                         DLLLib functions apart from the SWI veneers.  Do not
  28.                         define if the program being compiled will not be
  29.                         using Dynamic Linking at all.
  30.  
  31.                         Precisely, defining _dll_NODLL will make the
  32.                         following dllLib function calls into no-ops:
  33.  
  34.                           * _dll_appspace
  35.                           * _dll_clibdata
  36.                           * _dll_setname
  37.                           * _dll_setjmp
  38.                           * _dll_longjmped
  39.                           * _dll_giveMemory
  40.  
  41.                         It will also make the `safe *command' routines
  42.                         _dll_system etc. into direct calls to the `unsafe'
  43.                         versions (since we're not using SDLS, it doesn't
  44.                         matter).  Note that the header file currently uses
  45.                         RISC_OSLib routines os_cli and wimp_starttask for
  46.                         this: you should change dll.h to use OSLib or DeskLib
  47.                         versions of these functions as appropriate.
  48.  
  49.                         Finally, it will disable translation of
  50.                         _extEntry(name) into _extEntry_name.
  51.  
  52.                         Note that _dll_setname is a synonym for dll_nameApp
  53.                         invented specifically so that defining _dll_NODLL
  54.                         makes it a no-op.  It is recommended that you use
  55.                         the macro rather than the direct call in your own
  56.                         code.
  57.  
  58.         Note that you should never define both of these macros at the same
  59.         time.  Typical macro usage is shown in the table below.
  60.  
  61.         Compiling...            _DLL            _dll_NODLL
  62.  
  63.         code for a DLL          defined         not defined
  64.         code for a static lib   not defined     as for client
  65.         client using a DLL      not defined     not defined
  66.         client not using DLLs   not defined     defined
  67.  
  68. _____________________________________________________________________________
  69.  
  70.  
  71. The syntax for naming DLLs has been extended to allow DLLs to be held in
  72. directory heirarchies:
  73.  
  74.     The DLL Absolute Name (or DAN) is a way of specifying a DLL's
  75.     name (as described in its header) and the location of its file.
  76.     There are two styles of DANs:
  77.  
  78.       * A new-style DAN has the form [<path prefix>] `[' <DLL name> `]'.
  79.         This unambiguously specifies the DLL name, since it is enclosed
  80.         in square brackets, and provides information about the file's
  81.         location, if this is necessary.  If a path prefix is specified,
  82.         the DLL's filename is built simply by prefixing the DLL name with
  83.         the given path prefix.  If the prefix is not present, the DLL's
  84.         filename is built by prefixing the DLL name with `DLL:' so that
  85.         it is searched for in the DLLs resource.
  86.  
  87.       * An old style DAN has the form [<path prefix> `.'] <DLL name>.
  88.         If the prefix is specified, the DLL name is assumed to be the
  89.         leafname of the DAN.  The DLL's filename is the same as the
  90.         DAN.  This is provided for compatibility with older DLLs.
  91.  
  92.     Some examples will hopefully make this clearer:
  93.  
  94.         DAN            DLL name    Filename
  95.  
  96.         Steel            Steel        dll:Steel
  97.         [Steel]            Steel        dll:Steel
  98.         DLLs.MyDLL        MyDLL        DLLs.MyDLL
  99.         DLLs.[MyDLL]        MyDLL        DLLs.MyDLL
  100.         MyLib.Events        Events        MyLib.Events
  101.         [MyLib.Events]        MyLib.Events    dll:MyLib.Events
  102.         DLLs.[MyLib.Events]    MyLib.Events    DLLs.MyLib.Events
  103.  
  104.     The following SWIs now accept DANs instead of filenames:
  105.  
  106.       * DLL_Find should be passed a pointer to a DAN in R0.
  107.  
  108.       * The table passed to DLL_FindFromTable should contain pointers
  109.         to DANs.
  110.  
  111.     In addition, the command *DLLEnsure should be passed a DAN as its
  112.     first argument.
  113.  
  114.     Note that cdll from version 1.06 onwards will always generate the
  115.     new-style DANs.  We recommend that you always use the new-style
  116.     DANs in your own code, although we plan to remain compatible with
  117.     the old style indefinitely.
  118.  
  119. _____________________________________________________________________________